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This paper describes some of the environmental challenges associated with landing a 
crewed or robotic vehicle at any certified location on the lunar surface (i.e. not a mountain 
peak, permanently dark crater floor or overly steep terrain), with a specific focus on how 
hazard detection technology may be incorporated to mitigate these challenges. For this 
discussion, the vehicle of interest is the Altair Lunar Lander, being the vehicle element of the 
NASA Constellation Program aimed at returning humans to the moon. Lunar 
environmental challenges for such global lunar access primarily involve terrain and lighting. 
These would include sizable rocks and slopes, which are more concentrated in highland 
areas; small craters, which are essentially everywhere independent of terrain type; and for 
polar regions, low-angle sunlight, which leaves significant terrain in shadow. To address 
these issues, as well as to provide for precision landing, the Autonomous Landing and 
Hazard Avoidance Technology (ALHAT) Project was charted by NASA Headquarters, and 
has since been making significant progress. The ALHAT team considered several sensors 
for real-time hazard detection, settling on the use of a Flash Lidar mounted to a high-speed 
gimbal, with computationally intense image processing and elevation interpretation 
software. The Altair Project has been working with the ALHAT team to understand the 
capabilities and limitations of their concept, and has incorporated much of the ALHAT 
hazard detection system into the Altair baseline design. This integration, along with open 
issues relating to computational performance, the need for system redundancy, and potential 
pilot interaction, will be explored further in this paper. 
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Acronyms 


AFM 

Autonomous Flight Manager (software) 

km 

kilometer 

Altair 

Lunar Lander Vehicle 

LDAC-3 

Lander Design and Analysis Cycle-3 

AL 

Air Lock 

LEM 

Lunar Excursion Module 

ALHAT 

Autonomous Landing Hazard Avoidance 

LEO 

low-Earth orbit 


Technology 

LH2 

Liquid Hydrogen 

AM 

Ascent Module 

Lidar 

Light Detection and Ranging 

CARD 

Constellation Architecture Requirement 

LLO 

Low Lunar Orbit 


Documents 

LLV 

Lunar Lander Vehicle 

CEV 

Crew Exploration Vehicle 

LOI 

Lunar Orbit Insertion 

cm 

centimeter 

LOX 

Liquid Oxygen 

DEM 

Digital Elevation Model 

MET 

Mission Elapsed Time 

DM 

Descent Module 

NASA 

National Aeronautics and Space 

DOI 

De-orbit Injection (burn) 


Administration 

DRM 

Design Reference Mission 

ONSS 

Optical Navigation Sensor System 

DSN 

Deep Space Network 

OpNav 

Optical Navigation 

EDS 

Earth Departure Stage 

Orion 

Crew Exploration Vehicle 

ETDPO 

Exploration Technology Development 

PDI 

Powered Descent Initiation 


Program Office 

RCS 

Reaction Control System 

FPGA 

Field Programmable Gate Array 

RPODU 

Rendezvous Proximity Operations 

FSW 

Flight Software 


Docking and Undocking 

GN&C 

Guidance, Navigation, and Control 

TBD 

To Be Determined 


subsystem 

TD 

Touchdown 

HDA 

Hazard Detection and Avoidance 

THDSS 

Terrain Hazard Detection Sensor System 

HRN 

Hazard Relative Navigation 

TLC 

Trans-Lunar Coast 

HUD 

Heads Up display 

TRL 

Technology Readiness Level 

IMU 

Inertial Measurement Unit 

TRN 

Terrain Relative Navigation 

JPL 

Jet Propulsion Laboratory 
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I. Introduction 

Following the 2004 request of President George H. W. Bush to return humans to the moon by 2020 and then 
travel to such destinations as Mars, NASA formed the Constellation Program + to oversee the various activities and 
Projects associated with this goal. Under Constellation, NASA formed the Altair Project to develop the Lunar 
Lander vehicle that will perform descent from and ascent back to low lunar orbit, much like the original Project 
Apollo Lunar Excursion Module (LEM). However, unlike the original Project Apollo, the Constellation Program 
has levied additional requirements on the lander to be able to perform a precision landing at any location on the 
Moon, including scientifically interesting polar regions, which may ultimately require the real-time detection of 
landing hazards during final approach, though in a lighting environment that may be very poor to the un-aided 
human eye. Fortunately there is the Autonomous Landing Hazard Avoidance Technology (ALHAT) Project, an 
exploration technology development effort funded by NASA headquarters and working closely with the Altair 
Project, that is working to address these problems of real-time hazard detection and precision landing on planetary 
bodies. 

The Altair lander, as currently envisioned, is similar to the Apollo LEM in that it is a two-stage vehicle, 
comprised of a Descent Module (DM) and an Ascent Module (AM). Due in part to sizing constraints of launch 
vehicles, the Altair active mission phases will be more involved than that of the LEM. Initially the Altair vehicle 
will be delivered to Low Earth Orbit where is will rendezvous with the Orion crewed vehicle, similar to the Apollo 
Command and Service Module, and an orbital transfer stage that will accelerate the entire Altair/Orion stack onto a 
lunar transfer trajectory. Once on this transfer trajectory, the Altair DM will control the stack and implement 
trajectory adjustments and later a low lunar orbit capture maneuver, all functions that would have been performed by 
the Service Module of Apollo. For these reasons the DM is proportionately much larger relative to the total Altair 
vehicle than the Apollo DM compared to the Apollo-era LEM, which complicates landing area visibility from the 
AM during the final stages of landing. After the Altair/Orion stack is in a stable lunar parking orbit, the Altair 
vehicle will separate from Orion, conduct any orbital adjustment necessary to line up on target, then perform a de- 
orbit burn, followed by a coast and eventual powered descent leading to a soft landing on the lunar surface. Altair 
will be capable of landing four astronauts on the Moon and providing life support and a base for initial surface stays 
of modest duration. Using propulsion elements carried by the crewed AM, only the AM will ascend from the lunar 
surface, returning the crew to the Orion spacecraft that will bring them back to Earth. 


+ The future of the human space flight program, and thus the Constellation program, is currently being discussed at 
the highest levels of the U.S. government. For the purposes of documenting the Altair design, this paper is written 
without consideration of any forthcoming changes in the direction (or even existence) of the program. 
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The ALHAT Project has been overseen by the NASA Exploration Technology Development Program Office 
(ETDPO), and is chartered with developing sensors and algorithms that will guide a lander, with or without crew, to 
a precision landing on a planetary body. Furthermore this system will be able to detect landing hazards real-time at 
a slant range of approximately one kilometer from the landing site. The ALHAT Project originally preceded Altair 
by over a year, though since Altair was stood up, the two Projects, both managed out of the NASA Johnson Space 
Center, have cooperated where there were common goals, sharing information about potential mission and trajectory 
designs, as well as information about the lunar environment. 

This paper will discuss the current Altair vehicle and mission design as it relates to the lunar landing task, and 
will discuss the lunar environment as it relates to landing, particularly that of terrain and lighting. This paper will 
then explore some of the hazard detection options considered by the ALHAT Project along with the overall system 
design they are developing to accomplish this as well as precision landing goals. Finally, this paper will review the 
potential integration of the ALHAT hazard detection system into the Altair lander vehicle, along with some 
outstanding details and follow-on work to be addressed to 'flesh out' that integration. 

II. Altair Reference Design for Landing 

One of the most critical and dynamic phases of the Altair mission is the descent and landing phase. This phase starts 
just after de-orbit burn in Low Lunar Orbit (LLO) and ends with the vehicle's safe and precise touchdown near a 
predefined target on the lunar surface. The de-orbit burn immediately preceding this phase is a retro-grade bum 
changing Altair's orbit from a near circular orbit at 100 km above the reference surface into an elliptical transfer 
orbit down to 14.5 km (-47,500 ft) perigee where powered descent begins. 1 As envisioned by the Altair Project, the 
descent and landing phase consists of several sub-phases starting with the coast period along the elliptical transfer 
orbit, lasting about 56 minutes until reaching perigee. At this point Powered Descent Initiation (PDI) occurs as the 
powered flight begins at 92% throttle, thrusting into the velocity vector for the most efficient velocity reduction. 
This phase, with a slightly descending flight path to accommodate an optimal gravity turn, continues for just over 10 
minutes until almost all the horizontal velocity has been eliminated. 2 The Altair vehicle then begins the Pitch Up 
sub-phase, a maneuver intended as part of the transition to the Approach and near vertical Terminal Descent sub 
phases. Also at this time, the vehicle is throttling down allowing it to continue to descend in the low lunar gravity. 
The Pitch Up sub-phase is designed to be complete at 280 meters alt and just under one km uprange from the target 
where the Approach sub-phase begins, which is the only period where the crew can have a reasonably close view of 
the landing area to make further assessments of its suitability and safety. It is during this period the crew could 
command a late re-designation maneuver (similar to Apollo P64 mode) where guidance, within the performance 
limitations of the vehicle, steers to a new landing location. The Altair Approach sub-phase nominally lasts 77 
seconds, ending with the transition to final Terminal Descent at 30 meters altitude. During Terminal Descent, the 
vehicle descends near vertically at approximately 1 m/sec until soft contact on the surface, and with the main engine 
commanded to shut down at some modest altitude, 0.5 to 1 meters, to prevent thrusting at extremely close range that 
could introduce undesired touchdown dynamics. See Fig.l regarding the descent profile. 2 
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Figure 1. Altair Descent & Landing Profile 


While the Altair Project, interpreting Constellation requirements, defined 3 lunar mission reference categories, 
including Outpost (crew delivery to a base) and Cargo (unmanned delivery to a base), the prime focus of the Altair 
and related ALHAT efforts has been the definition of the lunar Sortie mission, envisioned to be a first time arrival of 
a crewed mission to a previously unvisited location. A lunar Sortie mission could include the first mission to a new 
outpost site. 3 As this is a first visit, it is assumed to not benefit from any surface or orbital high resolution (sub 1 
meter) a priori knowledge. Only that comparable to the Lunar Reconnaissance Orbiter (LRO) data, advertised as 1+ 
meter resolution in the best circumstances, is assumed available for a Sortie location. 4 That being the case, higher 
resolution data of the landing site, be it from a sensor or just the human eye, would not be available until the 
Approach and Tenninal Descent portion of the descent trajectory when the landing zone is reasonably in view, 
which then defines when hazard detection and avoidance could begin to occur. Prior to this point in the trajectory, 
the target is either over the horizon, blocked by the vehicle, or subtends too narrow of an angle of view for any 
terrain details to be discernable. 

For the current Altair reference mission described in Fig. 1 (consistent with the LDAC-3 design cycle), the 77 
second Approach sub-phase initiates at a slant range of 1 km and a slant angle, relative to the local horizon, of 15 
deg. This geometry works out to an average deceleration of approximately 1.05 lunar g's. 2 For the sake of fiill 
disclosure, only a very modest design trade was conducted by the Altair Project in defining this sub-phase trajectory, 
with the understanding that it would be revisited in more detail as the design matured. Still, the delta-v and 
corresponding fuel budget that Altair has been carrying since the closure of the LDAC-3 design cycle are based on 
this approach trajectory design. 


5 

American Institute of Aeronautics and Astronautics 


Powered Descent Initiation 

714 sec to Touchdown 
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Figure 2. Apollo Descent & Landing Profile 


For comparison, the first few Apollo landing missions (11, 12 and 14) each flew a 16 deg flight path angle and 
performed an initial pitch lip much earlier, at a trajectory point denoted as 'High Gate', roughly 8+ km up-range from 
the target and about 86 sec earlier than that planned for the Altair pitch-up. See Fig. 2 for the Apollo Descent and 
Landing Profile 5 and Table 1 for a comparison of manual flight time budgeted for Altair vs Apollo. 1-2,5 This early 
pitch-up cost some additional delta-v due to gravity losses, yet was beneficial in allowing the Apollo astronauts 
extra time for local terrain recognition and orientation as the target area would come into view. Also during this 
extended Approach sub-phase, the Apollo crew could re-direct guidance via discrete steps while in the P64 guidance 
mode based upon their window view of the target area. At some point late in the Approach sub-phase, usually past 
the 'Low Gate' but before the Terminal Descent, the pilot would transition into the P66 guidance mode which added 
a significant degree of manual control where the pilot could directly command attitude rates, and use this to 
indirectly command vehicle translation. Additionally the pilot could increment or decrement the descent rate, with 
guidance adjusting the throttle to accommodate. 5 

For comparison, the Apollo crew nominally began viewing the lunar surface 200+ sec prior to touchdown, while 
the Altar base line would allow for surface viewing at only 120 sec out, comparable to when the Apollo crew would 
be transitioning through Low Gate. As evident in Table 1, comparing delta-V and manual flight time budgets for 
various nominal and off-nominal events, the Apollo approach and landing strategy, matured for actual flight, 
includes several bits and pieces of additional manual maneuver time, some to cover nominal strategies while others 
provide for contingencies and margins. Those that were intended primarily to allow for manual piloting margin, as 
indicated by Ref 5, are denoted with yellow, while other budgets were included to accommodate autonomous 
GN&C or hardware performance dispersions. Altair is not budgeting for several of these, or is carrying a smaller 
amount for others, such as for re-designation, which is understandable as such delta-v maps to hundreds of 
kilograms of propellant. Overall Apollo is carrying 53+ seconds of flight time for manual piloting post Low Gate 
relative to the flight time included in the Altair design. Furthermore the hardware dispersions budgets could add 
time if those systems are performing well. 1-2,5 Still the Apollo approach, which was very pilot-centric including 
using the pilot as the hazard detection system, found it necessary to add this propellant. As such, if Altair intends to 
maintain smaller manual flight budgets and margin and accomplish a higher degree of landing precision (< 100 
meters), then some hazard detection automation and rapid target identification capabilities will likely be required. 
Adding to this is the Altair Project requirements calling for 100 meter landing precision 6 and with a design 
reference mission to the narrow crater rim (1 to 1.5 km wide) of Shackleton crater, a 19 km diameter crater 
encompassing the lunar south pole. 
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Table 1. Comparing Manual Flight Time Budgets between Altair and Apollo 


Event or Off Nominal 
Occurrence 

Altair AV 
(m/s) 

Altair (approx) 
flight time (sec) 

Apollo AV 
(m/s) 

Apollo (approx) 
flight time (sec) 

Pitch-up to TD 

-220 

122 

-375 

208 

Low Gate to TD 

- 190 

107 

- 190 

108 

Powered flight Dispersions 

53 

29 

53 

29 

Target re-designation budget 

5 

3 

18.3 

10 

Additional manual flight (hover) 

— 

— 

26 

15 

Engine valve malfunction 

— 

— 

11.4 

6 

Redline fuel sensor error 

— 

— 

12.1 

7 

Additional flight margin 

— 

— 

54 

31 


Another design facet distinguishing Altair from the Apollo LEM is the lander's much larger size. This is driven 
by mission requirements, including a larger crew size and longer mission timeline, and also by the Constellation 
Program requirement that the Altair Descent Module, as opposed to the Service Module of the Orion stack, provide 
the Lunar Orbit Insertion Delta-V, to accommodate size limitations of the Orion launch vehicle. The larger DM 
dimensions results in a larger footprint for the lander vehicle if reasonable landing stability is to be maintained. The 
present lander footprint is a circle of 5m radius, compared to that of the Apollo LEM being about 2.5m. A larger 
footprint decreases the chances of finding a safe touchdown location in a terrain of modest hazard density as a larger 
contiguous region free of obstacles must be found. This can be further complicated by the modest control and 
navigation dispersions that can manifest themselves even in the short time from when an ideal precision touchdown 
location might be identified at the beginning of the Approach sub-phase, to when the actual touchdown occurs. This 
could necessitate the addition of 1 or 2 meters onto the lander footprint that needs to be satisfied when searching for 
a suitable landing site real-time during the Approach sub-phase. 

Also, as with most planetary landers, there is a height tolerance in reference to potential obstacles, either rocks or 
craters, that the landing gear can accommodate while attenuating landing shock and maintaining the lander 
reasonably level after touchdown. The most recent Altair design requirements protect for 0.3 meters for tolerable 
obstacle height, 6 though there has been much discussion about the possibility of increasing this to 0.5 meters despite 
the associated mass penalty. 

In addition to obstacle height tolerance there is a maximum overall slope tolerance of the vehicle, measured 
basically as the maximum departure from local vertical by the vertical axis of the Ascent Module. The primary 
concern is to provide a reasonably level platform (within 12 deg) 6 from which the AM can lift off and not 
experience contact of its engine bell with any part of the DM, including the walls of the engine bell cut-out, or with 
any part of the Air Lock (AL), both of which remain on the surface. 

The limitations of the Altair lander baseline design with regards to maximum slope, tolerable obstacle height and 
large footprint size, directly indicate the need for some type of terrain and hazard identification system. This was 
the case with the original Apollo lander where the human eye and cognitive mind served as the terrain and hazard 
identification system by viewing and interpreting the lunar terrain through the window. However, the time available 
for such identification, along with the trajectory shape and its range-to-target history, directly relate to the hazard 
detection capabilities necessary to support a safe landing. In addition, lunar environmental factors, such as the 
general terrain and the local lunar lighting environment, also drive the requirements for a hazard detection system. 

III. Lunar Environment Challenges 

In addition to vehicle and trajectory design, many aspects of the lunar environment can be challenging to the 
execution of a safe and precise landing, and feed back to the lunar lander and mission design. These environment 
challenges basically fall into the two categories, terrain and lighting. Much work has gone into researching and 
characterizing these environments and how they relate to hazard detection. That work will only be touched upon 


7 

American Institute of Aeronautics and Astronautics 



here in an attempt to define the attributes of a hazard detection strategy that can support the Altair vehicle and lunar 
Sortie mission. 

The lunar terrain can most generally be categorized into two classes, mare and highland. The mare consists of 
two sub-classes, smooth and rough. However, both are defined as relatively younger than the highlands and were 
formed primarily by volcanism. The highlands, consisting of a 'hummocky' or smoother and more rounded hilly 
terrain, and 'rough', being a more rocky terrain, are both generally older, having been formed primarily by impact 
craters. 7 S Both the highlands, and to a lesser degree the mare, contain some large scale features that are detectable 
by remote observation from Earth or orbiting satellites, such as mountains, hills, or large craters, while just the mare 
includes large flat plains. In general, the large scale features are covered to varying degrees by smaller ones that are 
very difficult to detect from orbit. These smaller features are of primary concern as they can pose a hazard risk to a 
successful lunar landing by introducing the risk of vehicle damage, contact instability or excessive tilt. These small 
scale, potentially hazardous features consist mostly of rocks, craters and localized slopes, and have been the focus of 
several studies and statistical modeling efforts. 

Of the three features, rock frequency, expressed as a percentage of area, appears to vary the most, with increased 
frequency near fresh craters of sufficient size to eject bedrock. Rocks are also, in general, more present in the lunar 
highlands. Rocks were observed, through empirical counts of Apollo era photographic data, to be between 3 and 17 
% abundance (fraction of total surface area covers by rock) for various Apollo and Surveyor sites, which includes 
examples of both mare and highland terrain and which demonstrates the variability of lunar rock abundance. 9 Large 
craters appear to be more frequent in the older highlands which were exposed during early periods of heavier meteor 
activity. The frequency of smaller craters, of the 1 to 10's of meters range, are generally more constant across either 
mare or highlands at or near a saturation level, with an estimated value of ~0.1 craters, of 1 m size, per 100 meters 
square. 7 Mean slopes over long distances (tens to hundreds of kilometers) are generally the result of large scale 
observable features such as complex craters, basin rims, etc., and are rougher in the highlands due to the presence of 
a larger number of large scale impacts. In addition, mean slopes over smaller lander size distances (one to ten 
meters) have been estimated to demonstrate a slightly steeper value for highland terrain, with mean values of 6 to 8 
degrees (versus 4 to 6 degrees for mare) over a 10 meter base length. 7 Based on these general terrain characteristics, 
a landing near the rim of Shackleton crater in the lunar highlands will statistically be more likely to experience 
modest size rocks and steeper localized slopes than other areas of the Moon, though it would experience the same 
general density of small craters. 

Complicating the lunar environment further, particularly at the poles, are the extremes and limits to surface 
illumination. Over the period of a year, the lunar south pole will experience very low sun angles ranging from -1.5 to 
1.5 degrees. 7 To characterize this environment and bound the extremes of lunar lighting in support of the ALHAT 
Project, Andrew Goldfinger of the Johns Hopkins University Applied Physics Lab quantified the irradiance (radiant 
flux or effective illumination per unit area) that can occur on the lunar surface resulting from various sources, 
ranging from direct sunlight, to that reflected from the hilly illuminated earth (earthshine), to that reflected from 
other lunar topography, such as mountains, down to just starlight. These values are included in Table 2. The 
irradiance from a Liquid Oxygen / Liquid Hydrogen rocket engine, being the baseline for the Altair vehicle, is also 
included, as is the irradiance of a typical full moon as seen from the Earth. 10 These values are included here as they 
represent variations in the environment around the lunar poles, noting again that the rim of Shackleton Crater on the 
south pole is a reference mission target for the Altair Project, where at least the first mission will be a Sortie. With 
the low sun angle and the variations in local geography, it is evident that some areas will periodically experience 
direct sunlight while others will be temporarily or permanently shadowed from the sun. Some of these areas in 
shadow may still receive periodic illumination from earthshine or reflected lunar surface light from a nearby 
mountain peak or crater rim, while other areas will be in permanent shadow from all light sources other than 
starlight. It should also be noted that the plume of the Altair DM engine has vary limited irradiance and mostly in 
the infrared range, based on the ALHAT analysis. 10 
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Table 2. Comparative Irradiance of Various Light Sources 


Source 

Band 

Irradiance 

(W/m 2 /micron) 

Compared to Sunlight 

Direct Sunlight 

Visual 

2.1 x 10 J 

— 

Reflected Earthshine 

Visual 

2.7 x 10' 2 

1.3 x 10' 5 

Reflected Sunlight from Topography 

Visual 

1.0 x 10' 2 

4.8 x 10' b 

Full Moon on Earth 

Visual 

1.0 x 10' 2 

4.8 x 10 _/ 

Starlight 

Visual 

2.2 x 10' 6 

1.0 x 10' y 

LOX/LH2 Rocket Exhaust Plume 

SWIR 

1.0 x 10 -4 

4.8 x 10' S 


While some robotic probes or cargo missions may land during lunar darkness and, as such, not utilize any 
passive optical hazard detection sensors, a crewed mission, as envisioned by the Altair Project, will land at least with 
minimal sunlight as there is a Constellation requirement to have the crewed surface time be during daylight. 3 With 
the understanding that the landing target will experience at least some light, and with the assumption that some 
Altair Sortie missions would land at other higher latitudes, the Altair Project has engaged the ALHAT Project about 
the feasibility of landing utilizing only human vision, possibly augmented with optically enhancing goggles. The 
ALHAT Project executed three different studies related to this question S ltul exploring the limits of lunar lighting 
and the human eye. While much good work and detail exists in these references, only a few observations will be 
addressed here. 


Apollo 11 -14: Glide angle 16 deg 
Apollo 15 -17: Glide angle 24 deg 



Figure 3. Preferred Sun Angle During Lunar Landing 


One observation is that if direct sunlight exists, ideally it needs to have a certain geometric relationship, basically 
behind and below the viewing angle which effectively is the approach trajectory, to be of value in casting shadows 
that emphasize topography without generating glare. A sun angle directly behind or a little above the lander 
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approach angle would results in washout of lunar features or in glare off the surface. Still higher angles would cast 
little if any shadow, also limiting the visual identification of hazards. A sun angle below 7 deg to the surface begins 
to cast overly long and extensive shadows that hide surface features, according to an Apollo era analysis. 8 That 
same analysis determined the ideal sun angle to be between 7 and 13 deg, for a 16 deg Apollo 1 1 type approach, or 
between 7 and 20 deg, for a 24 deg Apollo 15 approach. See Fig. 3 which is mostly borrowed from one of the 
detailed ALFIAT analyses on the lunar environment and how it effects landing, 8 demonstrating ideal sun-angle 
geometiy for Apollo. Lunar Sorties to equatorial or mid latitude sites could satisfy this geometry by limiting launch 
windows (or utilizing extended loiter times on orbit). Flowever, these are not consistent with Constellation 
requirements to perform a mission at any time during the month or year. 3 Also, the aggressive Approach sub-phase 
time line may compromise the ability of a human to satisfactorily assess the target area. Furthermore, it should be 
noted that even with the ideal lighting and additional assessment time provided during the Apollo landing missions, 
some of the Apollo crews struggled with the identification of a safe landing site. 11 Finally, lunar Sorties to 
Shackleton crater or other polar regions will not be able to satisfy this desired sunlight geometry for any launch 
window or loiter adjustment as the sun angle is always too low. 

Setting aside the Apollo era recommendations for sunlight angle and further reviewing Table 2, it is evident that 
earthshine and even light reflected from lunar terrain can be several times brighter than the hill moon on Earth, 
potentially up to 27 times and 10 times respectively, for certain beneficial geometries. 10 These values still would be 
low for the best performance by the unaided eye but could potentially work with certain types of night vision or 
visual NIR type goggles, 10 at least with regards to providing the human eye with an enhanced version of what is 
optically available. Issues still may arise regarding the orientation of shadows from different light sources, and how 
that would vary throughout the month and year. Also, reflected light from a broad source, such as a crater rim or 
ridge, could produce a somewhat diffuse or washed out illumination of the surface of interest due to the partial 
Lambertian nature of the lunar regolith where it scatters light in various directions if it is not from a point source. 10 
Ultimately a more detailed analysis of the specific approach trajectory, coupled with the specific epoch, and its 
Earth-Sun-Moon relationship and resulting lighting environment, would be appropriate for exploring these issues 
further. Again, the optimization of lighting geometry may require significant constraints on launch windows, 
landing site locations, etc., that are not consistent with present Constellation or Altair requirements. 

IV. Hazard Detection Sensor Concepts 

As evident from the Altair vehicle and mission constraints, along with challenges posed by the lunar terrain and 
lighting environment, the rapid and detailed identification of hazards could offer significant benefit to the real-time 
actions of landing target assessment, selection and ultimate commitment. There would be additional benefit if such 
hazard identification could be derived from something other than passive optics (human or augmented) that rely on 
natural surface irradiance to provide topographic information. The ALHAT project has been exploring ideas along 
this line of reasoning, including a focus beyond passive optics, almost since its inception. 4 Furthermore the Altair 
Project, though not ruling out the possibility of passive optics including just the use of human vision, has generally 
acknowledged the difficulties posed with a lunar polar Sortie mission and, as such, has included in its baseline a 
hazard detection system and has been looking to the ALHAT Project to assist with its definition. 

At the core of such a real-time, hazard detection system is a hazard detection sensor that lends itself to rapid 
utilization. Several ideas for such a core sensor have been considered or evaluated including some, for completeness, 
that utilize passive optics. Some of these are described here though additional details are provided in the references. 
812 The following paragraphs list and discusses some of the key options for comparison, with the first four involving 
passive optical solutions. 

Human eye\ Though previously discussed with regards to lighting preference defined during Apollo, it can be 
further noted that the human eye has limitations both in spatial and contrast resolution. In ideal situations the human 
eye can discern 1 arc minute which maps to 0.3 meter objects at 1000 meter range, and discern 25 - 30 dB contrast 
in brightness once adapted to a lighting environment, though with the best contrast resolution (0.1 dB or 2 %) at the 
middle of the adapted range. With regions illuminated potentially from sunlight to earthshine to reflected light, the 
overall contrast range is likely to be comparable or greater than the discernable range with loss of resolution at the 
brighter and dimmer regions. 10 The spatial resolution is theoretically sufficient for the Altair mission, though 
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without a familiar reference, it may prove difficult to judge the size of hazards and even more difficult to discern 
slopes and depressions. Again, some Apollo crews struggled with this under ideal lighting. 12 

Human eye with Camera (or night vision) augmentation-. A camera or night vision type goggles offer better 
performance over the human eye alone if some reflected light (via earthshine or terrain reflection) is present, and if 
the signal-noise-ratio can be tuned for the appropriate contrast range and low light region of that range. Large 
aperture and zoom optics could both be employed to improve sensitivity and spatial resolution. Discerning size 
without a familiar reference, and inferring 3-D topography including subtle depressions (craters) and slopes from a 
2-D image, still is a potentially significant limitation. 12 

Human eye with Camera and Vehicle illumination-. This option has similar strengths and limitations to the 
camera option just described, but is included to note that the use of a vehicle mounted light source, in lieu of relying 
on direct or reflected illumination of the target zone, is also problematic. One issue is that a light source co-located 
with the observer results in a washout effect of the terrain with shadows not visible to the viewer, a similar issue to 
sunlight directly along the viewing or approach trajectory. Additionally, it may take substantial power to illuminate 
the target from 500 to 1000 meters out, when target re-selection and divert maneuvers are most fuel efficient and 
effective. 12 

Stereoscopic cameras'. If lighting of the target zone is sufficient, than this option could alleviate the difficulty of 
having to infer 3-D range and topographic information from a 2-D image. However, the baseline separation of the 
cameras to achieve this effect is prohibitive. For a range resolution of 30 to 50 cm (potential maximum tolerable 
obstacle size), even at a range of just 200 meters from the target zone, a camera separation of 10 meters is required. 

li 


Radar. In some ways comparable to the geometric limitations of the stereoscopic camera, the radar signal has 
inherent diffraction limitations, such that to even achieve a 0.5 deg angular resolution, a 50 cm radar aperture would 
have to be employed. Achieving smaller resolutions, as required to detect a 30 - 50 cm obstacle out to a range of 
1000 meters, would require an even larger aperture. 5 

Scanning Lidar: This option offers significant promise in that it can render a true 3-D topographic (or digital 
elevation) model of a target zone down to potentially a very small resolution, comparable to 30 - 50 cm. This 
technology, effectively launching a single laser pulse at a surface location being scanned and calculating range based 
on the signal time of flight, is also relatively mature. The issue with this approach is that to form a high resolution 
model or elevation map, as required for hazard detection, requires numerous (hundreds of thousands) of subsequent 
laser pulses, each aimed at a slightly different location by a rapidly articulating mirror. The estimated time required 
to scan a 180 x 180 meter target zone starting at 1000 meters is approximately 91 sec, by which time the vehicle 
would be on final vertical descent, if on an Altair trajectory. Additionally, individually correcting each return for 
vehicle motion and attitude change can be computationally significant and demanding. 13 

Flash Lidar. This technology, if it can be sufficiently matured, best addresses the above described issues and 
has been the baseline core sensor for the ALHAT approach to hazard detection. As such, it is the effective solution 
that provides placeholder specifications to the Altair vehicle and is in the latest baseline configuration. The concept 
effectively is a laser pulse launched and diffused, via optics, to strike and reflect off a region of the target zone, and 
then received by an array of pixel sensors. A series of these returns can be combined to render an elevation map of 
the entire 180 x 180 meter target zone, in what is estimated to be as little as 2 - 4 sec., vs 90+ seconds for the 
Scanning Lidar used in similar circumstances. Concerns with this approach, aside from the still developing maturity 
of the Lidar technology, also includes concerns about the significant computational overhead to process the returns 
and to generate useful hazard maps and usable digital elevation information. Still it is believed by the ALHAT 
Project, that 3-D terrain mapping and hazard detection processing can be accomplished for a target site of reasonable 
dimensions (180 x 180 meter) in less than 10 seconds, with a goal to get it under 5 seconds. 81113 

While several of the evaluated hazard detection sensor options appear to have substantial or unresolvable issues, 
a few still may offer some potential utility, possibly as part of a back-up option, if the related risk posture proves 
acceptable, or even as a primary system, if mission and vehicle design requirements are modified. The human eye 
with camera or other visual augmentation may yet prove sufficient if adequate lighting (equatorial or mid latitude) is 
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available and if launch window constraints are applied to ensure optimal lighting angles. Object size estimation and 
3-D inference of subtle hazards still poses a concern for this approach. But, with appropriate optics and with 
geometric assumptions on expected size based on attitude and trajectory, perhaps some of this can be compensated. 
Additionally, the Scanning Lidar may yet provide a solution if the scan area is significantly reduced or the tolerable 
hazard size significantly increased to reduce its execution time to a workable value. 

V. ALHAT integrated System 

The Autonomous Landing and Hazard Avoidance Technology Project was funded out of NASA headquarters as 
a technology development project to develop and mature technologies that would support autonomous precision 
landing on any planetary body in any lighting condition, with a near term focus on the moon, though with 
applicability to Mars and other planetary objects, including asteroids and Titan. While autonomous was in the title, 
the Project requirements call on the system to support either robotic or crewed missions, where for the latter the 
system would provide situational awareness at a minimum while also allowing for crew interaction ranging from 
just a flight manager approving a target to an active pilot using the ALHAT information as a reference. 4 

In supporting this charter, the ALHAT system evolved into three basic functions supported by a handful of 
candidate sensors and software algorithms. Some of these candidate components have now supported flight test 
while others are in the planning stages. These three basic functions necessary to accomplish autonomous precision 
landing include real-time Hazard Detection and Avoidance (HD A), the focus of this paper, along with Terrain 
Relative Navigation (TRN) and Hazard Relative Navigation HRN. Terrain Relative Navigation is a function that can 
be performed in lunar orbit as well as during descent coast and powered flight, and involves the refinement of the 
on-board navigation state via sensing surface topography and comparing it with onboard reference data generated 
from lunar reconnaissance missions, such as LRO. Finally Hazard Relative Navigation is a function that uses a 
subset of hazards or other surface features identified during final approach as navigation references, allowing the 
lander to steer to a safe target relative to the features identified in the HDA map. 4 Of these functions, the Altair 
Project is presently looking to ALHAT only as the source for the HDA function. While the Altair Project is 
interested in how ALHAT is pursuing the TRN and HRN functions, Altair has other strategies in its baseline for 
accomplishing these functions. 

For reference, a high level System Architecture schematic of the GNC system as viewed by the ALHAT Project, 
showing reference sensors, software and data paths, is included in Fig. 4, generated by Tye Brady and Jana Schwartz 
of Draper Labs for the ALHAT Project. 14 This figure has been modified to emphasize a few relationships, with 
modifications mostly in red noting the addition of gimbal hardware, the general grouping of the elements into three 
ALHAT categories (separated by a solid red line), and the addition of some transparent red boxes indicating lander 
GN&C elements that ALHAT is developing per their reference concept. A brief description of the elements in the 
figure follows, with additional discussion in the next section focused on how Altair presently would presently 
implement these ALHAT elements. 


12 

American Institute of Aeronautics and Astronautics 



Star Light 


Changes m 
angular rate and 
accelerations 


ALHAT SYSTEM 

HDA (& HRN) 


TRN 


/ Navigation / 

State A 

Estimate / 


f Key 


^GimbaT) 


~^T V 

HDA 

HDA 

Sensor 

Software 


TRN 

TRN 

Sensor 

Software 

^Gimba^ 

* J 


Lunar Map 

f 

Altimeter 

Altimeter 

Sensor 

Software 


▼ 

Veloameter 

Veloameter 

Sensor 

J ! 

Software 


Attitude 

Attitude 

Sensor 

Software 

M 

Gyro 

IMU 


Sensor 


M 

Software 


Exists with ‘Basic’ Lander 




Significantly 
Modified for 
ALHAT 


Vehicle State 
of Health 
Master Clock 

Commands 

Telemetry 


Representative 
► ALHAT Vehicle 
Control Software 


Effector 

Commands 


Figure 4. ALHAT Proposed GNC Architecture for a Precision Lunar Lander 

The grey-blue boxes and ovals represent hardware, either sensor or gimbals; the light grey rounded boxes 
represent software elements, the white rounded box (only one in the figure) is an a priori map element or database, 
the parallelograms are digital data packages, and the transparent red boxes are software functions resident on a basic 
lander design as implemented by ALHAT. Data flows are represented by arrows. 14 

The figure is divided into three sections with the top being HDA (& HRN) previously described. This function 
consists of the HDA sensor, presently assumed to be a Flash Lidar as discussed in section IV, mounted on a gimbal. 
The primary ALHAT concept has this gimbal being a fast articulating platform for the Flash Lidar, allowing it to 
scan several sub-areas of the target area per second, guided by the navigation state and 'area of interest' defined by 
the Navigation and Autonomous Flight Manager (AFM) software. These sub-areas are combined together as a 
mosaic by the HDA software and processed to define hazards. The hazard information is then provided to the AFM 
software which in turn defines a guidance target. The alternative ALHAT concept still under investigation may only 
require a slow moving gimbal, to track the moving target area as a whole, and using variable optics while repeatedly 
flashing the entire target area at a high rate, allowing the repeated images to jitter and use image processing 
techniques to extract high resolution topography. Again the HDA software would provide hazard information to the 
AFM, that in turn would define targets for guidance to use. The current ALHAT operations concept would generate 
these full hazard maps only once or twice during approach, though that philosophy is still being evaluated. After the 
initial hazard map is generated, the Flash Lidar would effectively become an HRN sensor in that it would collect 
individual frames of the area (set by lidar optics) for correlation with the hazard map developed by the HDA 
function. During HRN, key easily recognizable features are repeatedly tracked with their position known very 
precisely relative to the target. Using the Flash Lidar gimbal angles and range to features of interest, the lidar (and 
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vehicle) position can be determined very accurately relative to those features and, ultimately, to the safe landing 
target. 14 

The ALHAT TRN concept, used primarily from post de-orbit burn until the approach phase, uses a yet to be 
defined terrain sensor, quite possibly a laser altimeter or a flash Lidar with different optics, to generate altitude 
profiles or 3-D surface contours derived from the terrain below. These are compared with an a priori reconnaissance 
data set, already resident in the lander data stores, to observe and correct the difference between the estimated 
onboard navigation state, and the one observed. This TRN sensor could be fixed to the lander structure, articulated 
to maintain a nadir pointing vector, or gimbaled to enable the collection of additional data in the crosstrack 
direction. The TRN measurements are provided to the navigation filter to update the vehicle state. 14 

Finally, the remaining elements are sensors and software that would typically be included in a lunar lander 
design, though ALFIAT is suggesting a higher resolution velocimeter that will result in a smaller residual lateral 
velocity error at the start of terminal descent which, in turn, maps to a smaller safe landing site requirement. 
Otherwise, the core GNC software modules (navigation, guidance, telemetry, AFM) required for ALFIAT system 
testing are also required by a lunar lander, although some modifications would be needed to support ALFIAT 
functions. Some changes include the incorporation of lidar characteristics into the navigation filter, and the 
development of a guidance algorithm that can rapidly build a path to the precision safe target, as defined by the 
AFM software. 14 


VI. Altair Integration 

The Altair Project has interacted with the ALHAT Project for approximately three years, learning about the 
overall ALHAT system, component sensor and software element design, their assumptions and characterizations of 
the lunar environment and of the landing task, and all the while has provided feedback of their own Altair 
assumptions and occasional differences in perspective. The Altair Project, working to a modestly different set of 
assumptions (slightly less precision, landing with at least some lighting, etc), with different design philosophies and 
risk postures, and based on a strong priority to limit mass and a conservative philosophy of generally only using 
mature technologies, has sometimes differed with specifics of the ALHAT design solution. Additionally the Altair 
GNC design team has been working to design an overall GNC subsystem that can accommodate all Altair flight 
phases including orbital coast and powered flight ascent and rendezvous. If it is possible to use an already identified 
GNC component or software element to perform multiple functions, , then this different element may be substituted 
for that identified by ALHAT, based on specific circumstances. The Altair and ALHAT projects and their 
subsystem sensor and GNC teams have generally cooperated well, and the relationship has provided a valuable and 
productive exchange of ideas. 

Acknowledging the excellent world-class work of the ALHAT team and the impressive integrated autonomous 
GNC system design they have developed, the Altair GNC team and Project has worked to integrate elements of the 
ALHAT concept that were judged appropriate and consistent with the Altair design and philosophies. As such, a 
slightly different Hazard Detection System design, through drawing substantially from that of ALHAT, has emerged 
for the Altair team. This modified system, along with brief references to other GNC functions defined by Altair and 
ALHAT as they are presently envisioned to be integrated in the Altair vehicle, are discussed here. 

A. Incorporation of the Basic Hazard Detection System 

The basic HDA system, consisting of the upper elements as defined in Fig. 4, is currently envisioned to be 
integrated into Altair. The Altair GNC community has renamed it to be the Terrain Hazard Detection Sensor 
System or THDSS, but at present it is expected to be the core sensor developed and recommended by ALHAT. This 
would be a Flash Lidar mounted on a fast moving gimbal unless ALHAT determines an alternate configuration with 
a slow moving gimbal, also described in section V, works better. The only real difference regarding hazard 
detection is that the Altair team anticipates the HRN function will mostly shift to the ONSS (OpNav) system. 
Presently Altair is bookkeeping 10 kg mass for the THDSS assembly, though ALHAT field test articles (currently in 
the breadboard stage) are considerably more massive. Altair is presently carrying 150 watts for powering the hazard 
detection sensor and gimbal as well. Again the ALHAT development breadboard system is using considerably more 
power, although some of that is due to using less expensive terrestrial gimbals and thermal control approaches that 
must be optimized in terms of mass and power for spaceflight applications. So overall, the ALHAT team anticipates 
power numbers reducing significantly as well. The expected mounting location for the hazard detection sensor and 
gimbal is illustrated in Fig. 5 The sensor itself is not shown, though an arrow indicates its approximate location 
being very low on the forward facing structure of the Descent Module or even at the lower corner. This location 
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allows for maximum visibility of the target area starting with the powered pitch over and through the Approach and 
Terminal Descent sub-phase. If the instrument was mounted high on the Descent Module, or on the Ascent Module, 
then either the forward wall or the upper deck of the DM could block a portion of the hazard detection sensor view 
of the target area, particularly during early pitch over or later in the Approach sub-phase. The radar antennas, six 
total, serving as the sensors for both the altimeter and velocimeter functions for Altair, are located on a mounting 
platform, itself located on or near the lower aft corner of the DM, in a position where they can view the lunar surface 
during powered flight prior to, during, and after the powered Pitch Up, as it is critical to have an accurate altitude 
and velocity state to initiate the Pitch Up and subsequent Approach sub-phase. 
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Figure 5. Altair Lander with Proposed Hazard Detection and Other Sensor Locations 
B. A Brief Look at TRN and HRN 

Fig. 6 below, revisits the system architecture layout previously defined by ALHAT, demonstrating how the 
Altair GNC and avionics teams presently envisions the support of the various descent and landing functions that 
Altair will have to perform, including those defined in the ALHAT architecture. Again, some of these ALHAT 
functions will be served by other Altair GNC systems, identified to cover multiple mission phases. A prime example 
of this are the TRN and HRN functions which, in the Altair baseline design, are achieved via the use of the ONSS or 
Optical Navigation system, relying on the use of passive optical cameras. In the ALHAT approach, the HRN 
function is achieved using the HDA Flash Lidar system. For Altair, the Optical Navigation cameras were originally 
included to acquire position estimates while on orbit or in cis-lunar transit, in the event that deep space tracking 
information became unavailable. As Altair assumed that most of the descent coast and powered flight would be 
over terrain with at least some surface lighting, it was decided that the Optical Navigation system (shown in light 
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tan), could also perform the TRN task for approach and landing. Furthermore, as it was assumed that at least some 
elements of the target zone and nearby region would be illuminated, it was decided that effectively the same TRN 
approach could be used for the localized HRN or surface and target relative navigation performed during the 
Approach sub-phase up until vertical descent, except that new optical sensing of reference surface features might be 
compared to those generated some tens of seconds previously with a higher resolution, rather then those generated 
before flight. 15 This assumes that a method is identified to capture the precise location of the HDA identified safe 
target in the surface navigation frame being used by the ONSS. 

The remaining sensors were included in the Altair baseline as they would be required for descent and landing 
even if no HDA, TRN or HRN functions were to be performed, as any navigation system requires inertial sensors 
(gyros and accelerometer) for state propagation, and any planetary landing system requires ground relative altitude 
and velocity in order to control these key parameters for an acceptable touchdown. Altair assumed that both of these 
measurements could be sufficiently accomplished with the same radar system. However if the ALHAT requirement 
for a more accurate velocity sensor is later adopted by the Altair Project, then a different radar or a separate velocity 
sensor may be included in the Altair baseline. A GNC computer is required independent of HDA or TRN functions, 
as well. 



Figure 6. Altair High-level GNC Architecture with HDA, TRN and HRN 

Fig. 6, also for reference, shows several dedicated processors as light red boxes. These could be anything from 
fully reprogrammable digital computers to embedded FPGAs. As such, it can be observed from the figure that there 
is an emphasis on a decentralized and distributed task architecture, where possible, if a task can be relatively 
isolated, particularly one that is computationally intensive, or if there is advantage to having the task close to a 
sensor or even in utilizing an available underused processor. This enables potential execution efficiencies through 
parallel processing. Even so, the architecture still has a traditional GN&C computer that processes navigation tasks, 
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including state propagation and the combination of sensor inputs into a large navigation filter; guidance tasks, 
defining and updating reference trajectories; and control tasks, commanding RCS jets and TCV gimbals to 
implement guidance commands while maintaining stability. Red text listed among the GNC computer tasks, are 
those generally specific to the hazard detection function, included for reference. The GNC computer likely will also 
include a Flight Manager function to schedule tasks, initiate mode transitions along with reconfiguring software and 
sensors, and respond to commands, either from the crew or mission control. Separated from the GNC computer is 
the intense computational task of Hazard Detection and digital elevation model (DEM) generation required to 
assemble and orthorectify the data acquired from multiple Flash Lidar frames to form an elevation map. Similarly 
the ONSS sensor, performing optical navigation, would benefit from a dedicated processor to rapidly compare real- 
time optical data images with those taken a few seconds to over a minute earlier, or with lower resolution digital 
imagery generated from an earlier mission and stored onboard the lander. 15 

C. Computational Performance Concerns 

From the many face-to-face technology and integration discussions between both projects, an area of particular 
concern for Altair has emerged with relation to the computational performance required to support hazard detection. 
The concern basically is that there is no space qualified processor fast enough to process the data for a reasonably 
sized landing area, with sufficient resolution to detect hazards, and in a reasonable amount of time to support 
autonomous decision making and target redesignation. This concern is further amplified if it is necessary to provide 
fully processed landing site data to a crew member with sufficient time for them to assess and concur with any 
recommendations from the hazard detection and avoidance logic with regard to the selection of a safe precision 
target within the landing area. Preliminary lab benchmarks were showing time of roughly 1/3 to nearly 1/2 of the 
Approach sub-phase to complete all the hazard detection data processing such that a precision target could be 
selected and verified. While the Altair reference time-line of 77 seconds could be increased modestly to maybe 100 
seconds while not exceeding the HDA sensor range, this would cost some fuel. 16 And while there is some indication 
that higher performance space qualified processors will be available by the time of the Altair Project CDR (around 
2012 or 2013), the Altair Project still has concerns as this was not a guarantee and as the Altair Project has a more 
conservative philosophy to use existing technology whenever possible. Still, even with the use of existing 
technology for space qualified processors, there are some mission and vehicle design options that could help 
mitigate this concern, and some additional reason for optimism in that the hazard detection processing logic used in 
benchmarking the lab tests, has not been optimized. One very promising mitigation, appears to be an increase of the 
maximum tolerable hazard size of the lander, an option Altair is considering. A 30 cm maximum tolerable hazard 
was used for the initial benchmark. However if this is increased to 50 cm, processing times are reduced 
substantially. Another mitigation includes reducing the scan area from the baseline 180 x 180 meter, though this 
could increase the risk of not finding a satisfactory target site, possibly leading to an abort. Statistical analysis of the 
landing area, based on a priori remote sensing and hazard density models, would help in conducting such a trade as 
to the minimum size of a hazard scan area. More complicated operations strategies may offer some mitigation as 
well, where possibly a more coarse scan could be conducted early in approach and used to identify smaller target 
areas for subsequent detailed scans. Finally, there is good indication that a space qualified FPGA processor with 
sufficient performance could be made available in a reasonable amount of time. 


D. Back-up Hazard Detection 

Another Altair Project concern with the ALHAT Hazard Detection sensor relates to vehicle robustness and how 
to protect the crew, and possibly even the nominal mission in the presence of a prime Hazard Detection sensor 
failure. To this end, some type of back-up capability for the hazard detection function is judged necessary by the 
Altair Project. This could potentially be a hill up redundant hazard detection system, possibly from the same vendor 
though more likely a different vendor, or perhaps a different vendor for certain critical sensor subassemblies. This 
concern can also benefit from reviewing the candidates sensors considered previously. Many of the ideas still would 
not work outright due to overly limited performance, but there may be a few that, when combined with a higher 
mission risk posture and, perhaps, accepting an increased risk of an abort to orbit, may be able to serve as a back-up 
hazard sensor. One idea discussed earlier is the Scanning Lidar. Though much slower than a Flash Lidar, if a much 
smaller area is scanned (increased risk of a mission abort) or a larger hazard tolerance is accepted and a lower 
resolution scan preformed (increased risk of landing on a hazard), then a Scanning Lidar might could be employed 
as a backup. With this scenario, the use of human vision aided by a camera or goggle magnification might become 
acceptable as large hazards may be discernable with this approach. Still another remote option, might be to change 
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to the Rendezvous, Proximity Operations and Docking (RPOD) sensor, from a Scanning to a Flash Lidar, making it 
more common with the Orion RPOD sensor strategy. However with this change, and if the RPOD Flash Lidar is 
shifted to a forward location on the upper Ascent Module (AM) surface, then it might could also serve as a backup 
hazard sensor, though it would more limited visibility due to vehicle blockage of some of the landing terrain. 



Figure 7. Representative ALHAT Hazard Scan Map 


E. Pilot Interaction 

One final consideration regarding hazard detection integration is how it may interface with the lander pilot. This 
question is already being explored extensively by the ALHAT team, which has focused primarily on crew 
supervisory control and landing data interfaces during the descent and landing trajectory. However, it warrants some 
mention here. One question that has only been touched by some of the ALHAT crew interaction studies, is what role 
will the future crew member have? Is the crew member just to monitor displayed information, perhaps to only 
concur with a decision or abort? Or is the crew to be a little more involved and select from a list of targets or even 
identify a new target (in a P64 manner)? Or is the crew member to fly the vehicle in some manner (commanding 
attitude like Apollo, or commanding desired velocity) using the hazard scan data just as reference? The second and 
third options could require additional display information, such as the inclusion of detected objects smaller than the 
threshold to better assess landing selection. Also these latter options would likely benefit from more time on 
Approach, even if just 10 or 20 sec. For reference, Fig. 7 shows an example of hazard scan data as utilized in an 
ALHAT crew interaction study, where red indicates a hazard, 'bulls eye' circles represent targets and where some 
objects (rocks, etc) are shown even though they were below the hazard threshold. The white crosshairs near the 
center of the hazard scan area represents the a priori landing target selected by mission planners using lunar 
reconnaissance data. 17 

With the expectation that at least some surface features will be illuminated prior to and during the Approach sub- 
phase, it is suggested that the out-the-window view could be used as an initial confidence builder with regard to the 
higher resolution, active terrain sensing. A crew member could perform general navigation cross-checks with larger 
craters and other illuminated features prior to the Approach sub-phase by simply comparing the window view to a 
rendered display of a prior data, corrected for local view geometry and lighting. Additionally such out-the-window 
cross checks could be performed against Lidar sensed elevation data rendered in a display at the appropriate 
approach angle, and possibly even rendered on a HUD overlay. Fig. 8, a lunar DEM used in a recent ALHAT crew 
interaction study, represents what a synthetic image could look like, correcting for viewing angle, etc, though likely 
features would be presented with greater contrast, and those outside the hi-resolution scan area (green box) would be 
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rendered at a lower resolution. 1 7 This again would be to gain some confidence in the the hazard detection system, 
before trusting it to identify objects un-discernable to the un-aided eye. 



Figure 8. Potential Synthetic Imagery Example 

Another area of in-depth discussion between the Altair and ALHAT projects is the lander flight path angle 
during Approach. The Altair Project still assumes 15 deg, which is better suited both for crew visibility and lower 
fuel usage. However, the ALHAT Project, based on analysis, prefers a 30 deg minimum flight path to achieve 
reasonable sensor performance. A 30 deg minimum angle for the Flash Lidar reduces blockage of hazards behind 
others (shadowing) and reduces the downrange stretching of the flash lidar images relative to a shallower approach 
angle. 16 While 30 deg trajectories can be executed with only a very modest performance penalty (< 5 m/s) relative 
to 15 deg Approach trajectories, the reduction of crew visibility due to the steeper angle may be a more substantial 
issue. Perhaps the crew could get comfortable with this via out the window cross checks building confidence early 
during the Approach before the target disappears, or where cameras could then be used. This question will likely 
benefit from some of the additional data presentation and crew visibility studiers using simulation, that both ALHAT 
and Altair are planning. 


VII. Summary and Conclusions 

The need for hazard detection has been demonstrated based on Altair vehicle and mission characteristics, as 
well as the challenging lunar terrain and lighting environments, particularly near the lunar poles. Candidate hazard 
sensors were reviewed along with the case for the selection of the Flash Lidar as the hazard detection sensor of 
choice by the ALHAT team. The overall hazard detection and precision landing system architecture, as proposed by 
the ALHAT Project, which also includes the TRN and HRN functions, was presented. Finally, a discussion of the 
manner in which elements of the ALHAT system, particularly the hazard detection portion, could be integrated into 
the Altair vehicle was provided. The integration included just the use of the ALHAT selected Flash Lidar and high 
rate gimbal, along with landing zone processing and imaging software, which would run on a dedicated processor. 
Some Altair concerns regarding observed slow performance benchmarks of the hazard detection processing logic on 
a currently available space rated processor were discussed including mitigation options such as increasing the hazard 
tolerance of the lander. Thoughts on how to implement a back-up hazard detection sensor, with a desire for 
dissimilarity if possible, were also discussed. Finally, a brief review of how such a hazard detection system may 
interact with a crew member on the Altair vehicle was provided, with a focus on how out the window crosschecks 
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could be used to increase confidence in the system, and how the Altair Approach sub-phase trajectory may have to 
increase its flight path angle to accommodate Hazard Detection sensor performance. 

While some issues have been identified and reviewed here, overall it is believed that, should the Altair vehicle 
and project continue, its cooperation with ALHAT must continue with the likely outcome being the incorporation of 
their proposed Flash Lidar onto the Altair vehicle for hazard detection. Furthermore should the Altair Project go 
away due to changing NASA and Federal priorities, the hazard detection concepts developed by ALHAT should still 
be strongly considered for any planetary lander or asteroid encounter mission, and it is hoped that this study and 
review of how to integrate such a system into an overall vehicle, will be beneficial to some future effort. 
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